InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1992 / i / i254.asc < prev next >

Wrap

Text File | 1993-06-28 | 55.4 KB | 1,936 lines

Recommendation I.254 - Multiparty Supplementary Services The purpose of this Recommendation is to provide the stage 1 description of the method defined in RecommendationI.130 using the means given in RecommendationI.210. Supplementary services are described by a prose definition and description (step 1.1) and by a dynamic description (step 1.3). The application of the attribute technique, as defined in Recommendation I.140, for supple- mentary services is for further study. This Recommendation describes the following Multiparty Supplementary Services: I.254.1 Conference Calling (CONF) I.254.2 Three-Party Service (3PTY) I.254.1 Conference Calling Service Description 1. Definition Conference Calling is an ISDN Supplementary Service which allows a user to communicate simultaneously with multiple parties, which may also communicate among themselves. This description deals primarily with the establishment and manipulation of the connections used to form a conference call and is therefore expected to be applicable to many types of conference calls (e.g. voice, data, video, multi-media). Although provision is made for specifying the conference type, it is recognized that the control of conferencing functions (especially for other than speech) is beyond the scope of this Recommendation. This document describes the operation of add-on Conference Calling service only. Other forms of Conference Calling (e.g. "Meet-me") are not described. 2. Description 2.1 General Description When Conference Calling is invoked, conference resources (e.g.a "bridge") are allocated to the served user and any calls indicated by the service request are added to the conference. Once a conference is active, parties may be added, dropped, isolated (i.e. prevented from communicating with the conference), reattached, or split (i.e. removed from the conference but remain connected to the conference controller). The controller can place his/her connection to the con- ference on hold, retrieve the conference, end the conference, or disconnect himself/herself from the conference. 2.2 Specific terminology 2.2.1 Served user, conference controller, conferees, parties During the invocation phase, the service is under the control of the "served user" i.e. the one for whom the service was subscribed or, in those cases where subscription is not required, the one who invokes the service. Once the confer- ence is in the active state, the service is under the control of the "conference controller" who, in most cases, is the served user but could be a party other than the served user if transfer of control has occurred (an anticipated future extension to this service). Any party other than the conference controller is called a "conferee". All participants in the conference call are considered "parties". 2.2.2 Call Id, Party Id, Connection Id Call Id: The served user's (controller's) reference to a call of which he/she is a party (Examples: 1. The confer- ence call itself. 2. A call which is to be added to the conference. 3. A call which is formed by splitting a party from the conference). Party Id: The served user's (or controller's) reference to a particular party within the context of a call. Connection Id: The served user's (or controller's) reference to a particular connection (to a particular party) within the context of a call. Observe that multiple parties may be associated with a given call, e.g.a conference call. Moreover, there can be mul- tiple connections associated with a single party, e.g. a simultaneous voice and video call. Note - This service description assumes that there exists only one connection to a given party. Procedures to allow for multiple connection (e.g. multi-media conference calls) to a given party are anticipated future extensions. 2.2.3 Conference states Conference Idle: The state prior to the reception of a "conference invocation request", or after a particular conference has ended. Conference Active: The state in which conference resources have been allocated to the specified conference and at least one party has a connection to the conference. That connection could be either active or held. Conference Floating: The state in which the conference is active but without a controller. This state is possible when two or more conferees exist on an active conference and the controller successfully disconnects himself/herself (see SDL, sheet 7). 2.3 Qualification on the applicability to telecommunication services This supplementary service is considered meaningful when applied to the Telephony Teleservice and the speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services. 3. Procedures 3.1 Provision/withdrawal The Conference Calling supplementary service may be subscribed to by prior arrangements with the service provider. The subscription parameters include the maximum (and, if different, the default) number of conferees allowed in a conference call. Note - The default will usually be three, but may be six (or some other number). If the served user has subscribed to more than one size conference service and wishes to establish a con- ference of a size other than the default size, the served user must request the properly-sized conference before any parties are added to the conference. Withdrawal of the service is made by the service provider upon request by the subscriber or for service pro- vider reasons. 3.2 Normal procedures 3.2.1 Activation/deactivation/registration None identified. 3.2.2 Invocation and operation 3.2.2.1 Beginning the Conference Call (see Figure 1/I.254.1, sheets 1-2) a) Invocation parameters: Conference Calling service must be invoked by the served user. The invocation request must include the "root" Call Id, i.e.the Call Id by which the served user (or controller) will refer to the conference call itself. This Call Id may be either a new Call Id or the Call Id of an existing call which is to be used to form the conference. The invocation request may include the following additional information: - Conference size: The intended maximum number of parties for the conference (if different from the default). - Existing call/party information (Call Ids/Party Ids/Disposition of Related B-channel Connections): In order to initially include one or more parties from an existing call in the conference, the invocation request must include the Call Id, and optionally the Party Id and information as to how the B-channel associated with that call is to be handled. - New party information (called party address, other "setup" information): In order to initially include a party for which there is no existing call, the invocation request must include the desired party's address, and optionally other information contained in a normal call request. Note - Some information which is mandatory in a normal call request (e.g. "Bearer-Capability") can be inferred (e.g. from the conference type) and hence may not be mandatory here. - Connection request: either active or held. This request defines the served user's initial connection to the conference. Possible values follow: Active state specified: . Specific B-channel: a specified preferred/exclusive B-channel shall be used to immediately establish a connection to the conference. . Any available B-channel may be used. Held state specified: . Reserved B-channel: A B-channel is to be reserved for (later) connection to the conference. . No reserved B-channel: In this case no B-channel is allocated or reserved; the served user may have to free up a B-channel later when participation in the conference is desired. - Conference type: In general, the bearer capability compatibility check during context arbitration can be used to infer the type of conference required. It is assumed to be "speech". Other conference types may require special bridging facilities and/or higher layer control. - Conference bridge location: It should be possible to request the conference bridge to be at a specified location, e.g. close to some grouping of conferees. Procedures for remote location of conference bridge facil- ities are anticipated future extensions. b) Defaults for invocation parameters If any of the information described above is not included in the invocation request, the following defaults will occur: - Conference size: Defaults to the subscribed default conference size specified at subscription time (if the served user specified a default conference size at subscription time) or the subscribed maximum conference size (if a default conference size was not specified), or the service provider - specified default conference size (if the served user did not subscribe to the service). - Existing call/party information: . Call Ids: If no Call Id other than the root Call Id is specified, no existing calls will be initially included in the conference. . Party Ids: If not specified, each party (other than the served user) of the indicated Call Id(s) will be initially included in the conference. . Disposition of related B-channel connections: if disposition information is not included, the related B-channel connections will be deallocated, unless the service provider chooses to use them for connection of the served user to the conference call (e.g. in a multi-media conference). - New party information: . Called party address: if not specified, no new parties will be initially included in the conference. . Other "setup" information: for further study. - Connection request: If no connection information is included, it is assumed that the served user wishes to be initially connected to the conference in the active state and any available B-channel may be used. . If the served user indicates that he/she wishes to be connected to the conference in the active state but does not indicate "Specific B-channel" or "Any available B-channel", it is assumed that any available B-channel may be used. . If the served user indicates that he/she wishes to have his/her resulting connection to the conference to be in the held state, but does not indicate "reserved B-channel" or "No reserved", it is assumed that a B-channel is to be reserved for (later) connection to the conference. - Conference type: If not specified, the service provider will attempt to derive the appropriate conference type from the bearer capabilities of the call(s) involved. If no calls are knownby the service provider to be involved in the call, the default conference type shall be "speech". - Conference bridge location: If not specified, the service provider will attempt to place the conference bridge(s) in the most appropriate location, considering the call(s) known by the service provider to be involved at the time the request is made. c) Procedures When a conference request is made, a conference call is set up. When the service provider receives the request to allocate resources for the conference call, it checks to see that the requested conference can be established. This procedure is termed "Context Arbitration". Context Arbitration includes a bearer capability compatibility check, a supplementary services compatibility check, a check to see that the state of each connection to be added is acceptable, and a check for the availability of conference/network resources. Upon successful completion of the context arbitration, the resources needed are allocated. If the conference request is successful, all existing appropriate call(s) referenced in the conference request are added to the conference. (Note- Adding parties from an existing call may not be successful in all cases due to remote bridging and rerouting lim- itations.) Upon successful joining of the specified parties to the conference, any unused B-channels are deallocated and any single party calls are released. The service provider checks the conference request for additional information (optional parameters). For those optional parameters not included in the conference request, the default values will be used. In addition, if the connection request parameter is not included and no additional parties are indicated (i.e. m = °, n = °) the service provider will prompt the served user for further actions. C.1) Prompting procedures detected: If the number of referenced existing calls (other than the root CallId) in the conference request is zero and the con- troller connection request is not included; the conference is put on hold from the served user's point of view and the served user is prompted for further actions (i.e. the add-party procedure is automatically started). C.2) No prompting procedures detected: If the number of referenced existing calls (other than the root CallId) in the conference request is larger than zero, or if the controller connection request is specified, the referenced calls are automatically connected to the conference, which is now in an active state. The served user's connection to the conference will also be active unless the controller has indi- cated that his/her connection to the conference be held. The decision to put the conference on hold or not (from the served user's point of view) is based on the information received in the Conference Request, independent of the number of referenced existing calls. 3.2.2.2 Managing individual parties (see Figure 1/I.254.1, sheets 2-3) When managing a party, the controller needs to specify the pair CallId/PartyId. If no Party(s) is specified, the service provider will typically assume that the request applies to all parties associated with the indicated Call Id. (Exception: If Party Id is not specified in the drop party command, the last party added to conference is dropped.) In the active state of the conference, the conference controller has the following options for managing parties in asso- ciation with a conference: Add new party: The conference controller can request that a new party be added to an existing conference call using procedures analogous to those used to start the conference call. Upon a request for the addition of a new party, the conference controller automatically puts the conference on hold. The service provider checks the ADD-request for additional information, i.e. whether or not the conference controller is to keep the conference on hold after the addition of a new party. If no information is received, the service provider will use the service default value. When on hold, the conference controller can either indicate the address of a new party or indicate a Call Id of an already existing call. (See SDL, Sheet 2.) . New call: The service provider will establish a connection with the new party indicated by the address provided by the controller. Upon call establishment, the controller will be connected to this new active call. (If call establishment fails or if the active call is disconnected, the controller may or may not return to the active Conference based on the connection request parameter within the "Add Party" request). (Note - By establishing this connection via the conference bridge, the service provider may avoid problems associated with remote bridging and rerouting). . Existing If a Call Id exists, the controller indicates a call: Call Id to be added directly to the conference. The party (parties) on the indicated call are immediately joined to the conference. If a Party Id is given in conjunction with the Call Id, then the specified party is split from the specified call and added to the conference. If no Party Id is given then all parties on the specified call are added to the conference. (Note - Adding parties from an existing call may not be successful in all cases due to remote bridging and rerouting limitations). Drop party: The conference controller can request that a specified party be disconnected from the conference and the con- ference controller's association with that party be eliminated completely. If no Party Id is specified, it is assumed that the last party (if identifiable) added to the conference should be dropped. After the party is dropped, if there are no other conferees (Note - A conferee is a party other than the conference controller), then the conference remains in the "Conference Active" state (with only the conference controller attached). If, after the party is dropped, there is only one other conferee, then the service provider could, at its option, form an "ordinary" two-party call and release the conference resources, or remain in the "Conference Active" state (with only the conference controller and the one conferee attached). (See SDL,Sheet 3.) Split party: The conference controller can request that a specified party be removed from the conference but remain connected to the conference controller. Performance of this request requires that the network establish a new CallId for the call between the conference controller and the specified party, since that party is no longer associated with the conference call. Two parameters must appear in the split party request: 1) Call Id (conference call), and 2) Party Id (specified party). The "Split Party" request will put the controller's connection to the conference in the held state and the controller's connection to the specified party in the active state (see SDL, Sheet 3). Isolate party: The conference controller can request that a specified party be prevented from communicating with the Conference but not removed from it. This does not affect the state (e.g. Active or Held) of the specified party's access channels (e.g. B- channels) which are nominally under the control of the specified party. (See Figure 1/I.254.1, sheet 3.) Reattach The conference controller can request that the specified party party: be reattached to the conference. Successful execution of this command permits a previously isolated party to again converse with all other parties that are connected to the conference. (See Figure 1/I.254.1, sheet 3.) 3.2.2.3 Managing the conference (see Figure 1/I.251.1, sheets 4-5) In addition, the conference controller can manage the complete conference in any of the following ways: Hold The conference controller can request that his/her own connection conference: to the conference be held using procedures as described in the Call Hold service. Successful execution of this command retains the existing state of conferees in relation to the conference, i.e. those who could communicate with each other can still do so and those who were in an isolated state remain in that state. (See Figure 1/I.254.1, sheet 4.) Retrieve The conference controller can request that a conference conference: controller's connection to the con- ference be retrieved (see hold conference description above). Successful execution of this com- mand retains the existing state of conferees, i.e.those who could communicate with each other can still do so between themselves as well as the conference controller, and those who were in an Isolated state remain in that state. (See Figure 1/I.254.1, sheet 4.) Interrogate: It is an anticipated future extension that the conference controller is able to request the current status of the conference call (i.e. number of parties, identification of parties, etc.) from the service provider. Information content and procedures for the interrogate request are, as yet, undefined. (See Figure 1/I.254.1, sheet 4). Disconnect: A "Disconnect" request from the controller will disconnect the controller from the conference, and may, in some cases, result in ending the conference. From the controller's perspective, this disconnect procedure is iden- tical to that outlined in the Basic Call service description. If: a) the number of conferees is greater than or equal to 2; and b) Float Conference option is subscribed to; and c) Float Conditions (e.g. charging) are satisfied; then the conference goes to the Float State. Otherwise the conference ends (see end conference). This procedure differs from the "Disconnect Controller" procedure in that the normal disconnect procedure can result in either the Conference Active or Conference Idle state. When "Float Conference" cannot be per- formed, instead of the controller being notified, disconnect processing continues with the release of con- ference resources. (See Figure 1/I.254.1, sheet 5). Disconnect The controller can request that he/she be disconnected controller: from the conference. If the number of parties is greater than or equal to 3 and if the controller has sub- scribed to the "Float Conference" option, and provided charging or other restrictions are not violated, the connection of the controller will be cleared and the con- ference proceeds to the Float State (i.e. the remaining con- ferees could continue to communicate). Otherwise, the controller would be notified that the "disconnect controller" request is denied and the conference remains active with the controller still connected. The remaining parties will stay on the conference without a controller until less than two conferees exist on the conference. In a conference without a controller, conferees can only hold, retrieve or drop their own connections. If one or two parties (including the controller) exist on the conference at the time disconnect is requested, the controller would be notified that the disconnect request is denied and the conference remains active with the controller still connected. (See Figure 1/I.254.1, sheet 5). End The conference controller can request that the conference conference: be terminated, i.e. 1) that every party associated with a particular conference be disconnected, 2) that all conference resources be deallocated, and 3) that all knowledge of the conference call, including the Call Id, be removed. (See Figure 1/I.254.1, sheet 5). Note - While "Disconnect Controller" and "End Conference" provide usefulunambiguous functions, it is recom- mended that all terminals include the "Disconnect" function, and that this be the request that is sent in response to the normal user action (e.g. hanging up the telephone). This will avoid the following problem: the controller may "hang up" and leave the terminal before receiving notification that a "Disconnect Controller" request cannot be accomplished. The "Disconnect" request would allow processing to continue at this point and the conference would be ended. 3.2.2.4 Possible actions by conferees (See Figure 1/I.254.1, sheet 6) In the active state of the conference, the conferee can: Hold/retrieve: Put his/her connection to the conference on hold and later retrieve it. (See Figure 1/I.254.1, sheet 6). Disconnect from the conference: The procedures here are nominally the same as those that occur after a con- feree has been dropped from a conference by the conference controller. (See figure, sheet 6). Indication of the above actions by any conferee should be provided to the conference controller. Whether conferees also receive indications as to the actions of other conferees is for further study. 3.3 Exceptional procedures 3.3.1 Activation/deactivation/registration None identified. 3.3.2 Invocation and operation 3.3.2.1 Beginning the conference call If a user tries to invoke Conference Calling and the service provider cannot comply with that request, the service provider will deny the request and explain the reason for denial. Possible reasons for non-compliance are: - service not subscribed; - resources cannot be allocated; - served user (or intended conferee) restrictions not met; - context arbitration check failed; - more than one party in an alerting state. If multiple conferees are specified in the conference request and if the context arbitration failed for only a subset of the intended conferees, the service provider has the option of permitting the subset of conferees which passed the context arbitration to form the initial conference call. If this is not permitted, the failure of any of the requested parties to pass the context arbitration check causes the conference request to be denied. 3.3.2.2 Managing individual parties Add new party: If the service provider cannot satisfy an "Add New Party" request (e.g. if the conference call has been cleared or if the maximum number of conferees allowed has already been reached) the con- ference controller will receive indication that the request is denied, with the reason for failure. [Note - It is an anticipated future extension to allow for conference resizing when there is an attempt to exceed the maximum conference size allowed.] Failure to pass any of the checks associated with the context arbitration results in the return of a failure message to the conference controller with appropriate cause(s). Split isolate party: If no Party Id is included in a "Split Party" "Isolate Party" request, notification of failure is returned to the conference controller. If the controller sends an "Isolate Party" request concerning a party which is already isolated, or a "Reattach Party" request concerning a party which is already attached, the network will ignore the request. 3.3.2.3 Managing the conference No exceptional procedures identified. 3.4 Alternate procedures None identified. 4 Network capabilities for charging This Recommendation does not cover charging principles. Future Recommendations in the D-Series are expected to contain that information. It shall be possible to charge the subscriber accurately for the service. 5 Interworking requirements None identified. 6. Interactions with other Supplementary Services 6.1 Call Waiting Once a conference has been established and the following parties have subscribed to the Call Waiting service: i) any party that has activated Call Waiting will be able to receive an indication of an incoming call, and could place the conference on hold to accept the waiting call; ii) the Conference Controller could, if desired, add the party from the waiting call by answering the waiting call and using the "add party from existing call" procedures. Note - If either the conference controller or a conferee has accepted a waiting call and has subscribed to either (minimal) Three-Party Service or Call Hold Service, then this party could alternate between the call waiting call and the conference. 6.2 Call Transfer Conference controller: A conference controller may transfer the conference to a party not on the conference, but "control" cannot be trans- ferred (Figure 2/I.254.1, case a)). The transfer of control of a conference to another party on the conference is an antic- ipatedfuture extension (Figure 2/I.254.1, case b)) not yet included in this service description. A conference controller may disconnect himself/herself from the conference (Figure2/I.254.1, case c)) which may result in the conference entering a "Float" state (see text). Conferee: A conferee should be able to transfer his/her connection to a conference (Figure 2/I.254.1, case d)) to another party. Only the "normal" and "explicit" forms of transfer should be used, and the "Complete transfer" request should only be made after the call to the other party has reached the active state. (This is to prevent call progress signals from disrupting the conference.) The identity of the new party, if available and unrestricted, should be given to the conference controller. Any Party: Any Party on a conference may transfer calls, or receive transferred calls, that are independent from the conference. A conference controller can add a call transferred to him/her using the "Add Party from Existing Call" procedure (Figure 2/ I.254.1, case e)) (see text). A conference controller can "transfer" a call to a conference (Figure2/I.254.1, case f)). (This is functionally similar to the case shown in Figure2/I.254.1, case a).) A conferee may explicitly transfer an incoming call that has reached the active state to a conference (Figure 2/I.254.1, case f)), but this results in the conferee being disconnected from the conference, as in the case shown in Figure2/I.254.1, case d); it is not a form of "add party". Any party in a conference may place the conference on hold, and explicity transfer another party that is being held. For example, user A is active in a conference call and also has a party B on hold (B is thus not part of the conference). User A may place the conference on hold and "explicitly" transfer party B to another party. Calls may be transferred to any party of a conference while that party has the conference on hold. A conferee receiving a transferred call would not be able to add the transferred party to the conference. A conference controller receiving a transferred party would be able to use the "Add Party from Existing Call" procedure to add this new party to the conference. 6.3 Connected Line Identification Presentation A conference controller who has also subscribed to COLP should be presented the connected party's number when the party is either part of the initial activation of the conference or is added as a new conferee to an existing conference. Con- ferees in an existing conference who have subscribed to COLP will not receive a new party's number whenever a conference controller adds a new party to the conference. 6.4 Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.5 Calling Line Identification Presentation Any party that has subscribed to CLIP will receive the address of the conference controller when: - the party is to be included as a "New Party" during the invocation of a conference call, or - the party is being added to an existing conference call. 6.6 Calling Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.7 Closed User Group The conference controller and all conferees must belong to the same CUG. When establishing the conference initially or when adding a new conferee, CUG restrictions must be checked and met for all parties on the conference call before the (new) party is allowed to enter the conference. 6.8 Conference Calling A conferee may be connected to more than one conference if he/she has also subscribed to the Hold Service. The con- feree could switch between the conferences by placing one conference on hold and retrieving the other conference. (See also section 6.12 for the interaction with Three Party Service). 6.9 Direct Dialling-In No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.10 Diversion services A call which has been diverted can be added to a conference by the conference controller or be part of a new conference when initially invoked by the served user. 6.10.1 Call Forwarding Busy See 6.10 above. 6.10.2 Call Forwarding No Reply See 6.10 above. 6.10.3 Call Forwarding Unconditional See 6.10 above. 6.11 Line Hunting No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.12 Three-Party Service (see Figure 3/I.254.1) It should be possible for a conference controller who has also subscribed to (minimal) Three-Party Service to participate in two conferences, and alternate between them (Figure 3/I.254.1, case a)). It should not be possible to use (Full) Three- Party Service to join the two conferences (Figure 3/I.254.1, case b)). Procedures for joining conferences via normal "add party" functions are described in the text. It should be possible for a conferee who has also subscribed to (minimal) Three Party Service to participate both in the conference and in another call (which mayor may not be a conference) and alternate between them (Figure 3/I.454.1, case c)). It is highly undesirable, and may, in some networks be prohibited, for the conferee to use (Full) Three-Party Service to bridge the conference and the other call (Figure 3/I.454.1, case d)). This is due to the reduced control the conference con- troller would have regarding the party(ies) on the other call. Example: a conference controller request to drop the conferee that invoked Three-Party Service would drop the conference connection to all of the parties on that three-way call (Figure 3/I.454.1, case e)) but would not, in fact, disconnect any of them; they would remain active with Party C. 6.13 User-to-User Signalling The conference controller will be able to send UUI (Service 3) to any conferee on a conference call individually, and in some networks optionally broadcast messages to all conferees. (Note - This assumes that each conferee can be uniquely identified.) UUI can be received by the conference controller from any of the conferees. While adding a new party to the con- ference, the conference controller can send and receive UUI (Services 1, 2 and 3) from the new party until the new party is added to the conference. A conferee may send and receive UUI (Service 3 and Service 1 during call clearing phase) from the conference controller. UUI cannot be sent between the conferees in association with the conference call. (Although any two parties, if subscribed, could send non-call associated UUI to each other.) A conferee's ability to send broadcast messages (under the control of the conference controller) to all parties, is for further study. A conferee may send UUI (Service 1) to the conference controller only during the call clearing phase. 6.14 Multiple Subscriber Number No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.15 Call Hold Service When establishing a conference, the served user may identify any party(s) it has on hold to become a conferee(s) in the conference call being established. Similarly, a conference controller may add any party he/she has on hold to an active con- ference. A party (A) in a conference may place the conference on hold and retrieve some other party that party A has on hold. Party A may then place this call on hold to retrieve the conference call. Assuming subscription to both the Conference Calling and Call Hold services, a party may: i) be a conference controller of two or more conferences. The conference controller switches conferences by putting the active conference on hold and then retrieving another conference; ii) be a conference controller of one conference and a conferee of another conference(s). The party may switch between conferences by putting the active conference on hold and then retrieving another conference. 6.16 Advice of Charge No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 7. Dynamic Description The dynamic description of this service is shown in Figure 1/I.254.1, sheets 1-7. I.254.2 Three Party Service Description 1. Definition The Three-Party Service enables a user who is active on a call to hold that call, make an additional call to a third party, switch from one call to the other as required (privacy being provided between the two calls), and/or release one call and return to the other. Optionally, the served user could subscribe to an ability to join the two calls together into a three-way conversation. (Relationships between this service and the Call Transfer supplementary service are indicated throughout the text and SDL's). 2 Description 2.1 General description Three-Party Service provides a user with flexibility in handling up to two (initially-) independent calls. Different forms of the service exist which allow the user to control these calls. The various forms of Three-Party Service are given below. +ûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ |Form of | . Hold Existing Call | . Form Common Path ||Service | . Make Call to 3rd Party | Between All Three | | | . Alternate Between Parties | Parties |+ûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ |Minimal | Yes | No ||Service | | |+ûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ |Full Three- | | ||Party Service | Yes | Yes |+ûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ûûûûûûûûûûûûûûûûûûûûûûûûûûûû+ In principle, all participants in a Three-Party Service call should be informed about the state of their calls whenever nec- essary. 2.2 Specific terminology Call ID: The served user's reference to a call of which he/she is a party. Examples: 1) the call to user B (or user C) prior to its being used to form a three-way conversation; 2) the three-way conversation, once it is formed. Served user: During the invocation and active phases, the service is under the control of the "served user", i.e. the one for whom the service was subscribed. This user is also referred to as "user A". user B: The other party in the original call (A<->B). User C: The "third party" - the other party in the second (e.g. enquiry) call (A-->C). [For the original call, the served user may have been either the calling or called party (i.e. it may have been either an incoming or outgoing call).] 2.3 Qualifications on the applicability to telecommunication services This supplementary service is considered meaningful when applied to the Telephony Teleservice and the speech and 3.1 kHz audio Bearer Services. Furthermore, it may also be meaningful when applied to other services. 3. Procedures 3.1 Provision/withdrawal The Three-Party supplementary service is subscribed to by prior arrangements with the service provider. Subscription can be made for the "Minimal Service" or the "Full Three-Party Service". Withdrawal of the service is made by the service provider upon request by the subscriber or for service provider reasons. 3.2 Normal procedures 3.2.1 Activation/deactivation/registration None identified. 3.2.2 Invocation and operation 3.2.2.1 Beginning Three-Party Service (see Figure 1/I.254.2, sheet 1) The served user, user A, who has an existing active call with user B, asks the service provider to begin the Three-Party Service. The service provider puts the existing call on hold. User A then proceeds to establish the second call (to user C). [Note - The same actions take place when the served user asks the service provider to start the "Normal" Call Transfer ser- vice (see Call Transfer service description). Conceivably, a similar "Held && Active" service state could be attained as a result of accepting an incoming call in such a way that the service provider knew to associate that incoming call with the existing call and, hence, put the existing call on hold (see Call Waiting service description for one such possibility).] 3.2.2.2 Managing two associated calls - one held, one active (see SDL, sheets 1-2) Served user: Once the call to the third party reaches the alerting state, the served user can: i) alternate from one call to the other as required (possibly several times), privacy being provided between the two calls; Note - The exact interactions between the served user and the service provider depend somewhat on the information and control capabilities available to the user from his/ her terminal. Compare the two methods of alternating between calls given in Figure 1/I.254.2 under "Alternate" vs. "Return to A->B(C)". ii) Disconnect the active party (e.g. user C), whereupon the service provider would notify (Note) the served user that the other party (e.g.User B) is still held and wait for one of the following events: - request from the served user that held party be retrieved; - request from held party to disconnect. If neither event occurs within a brief time interval, the service provider will disconnect the held party. Note - This would be a "high priority notify", i.e. one capable of gaining the served user's attention if he/she was away from the terminal. Ringing is an example of this. iii) Disconnect the held party (e.g. user B) Note - Disconnecting a held party without previously retrieving it is considered undesirable for a "human-to- human" call but may be useful in other cases; or, if subscribed for: iv) request the service provider to begin a Three-way conversation (see managing an active three-way conversation below). Note - In some networks, the served user can invoke this step only after the call to the third party reaches the active state. Active party: If the active party disconnects, the service provider would notify the served user that the other party (e.g. user B) is still held and wait for one of the following events: - request from the served user that held party be retrieved; - request from held party to disconnect. If neither event occurs within a brief time interval, the service provider will disconnect the held party. Held party: If the held party disconnects, the service provider will clear that connection, resulting in a simple active call between the served user and the currently-active user. 3.2.2.3 Managing an active three-way conversation (See Figure 1/I.254.2, sheet 3) Served user: During an active three-way conversation, the served user can request that the service provider: i) end the three-way conversation; Note - Signalling procedures for disconnecting a multi-connection call are not yet defined. ii) disconnect himself/herself from the three-way conversation. Since the served user is also the controller (and normally the one that is charged for the call), this shall result in the entire three- way call being cleared. Note - An anticipated future extension to this service and the Call Transfer service is the ability to negotiate charging and control responsibilities, thus permitting the call to continue after the served user has disconnected (See Figure 1/I.254.2: Call Transfer from "Active Three-Way Conversation" State). iii) explicitly disconnect one of the other parties which would result in a simple active call between the served user and the remaining other party; iv) place his/her connection into the conversation on hold (and, typically, later retrieve it). Note - While the served user is held, the other parties (B and C) may continue to communicate. v) split off one of the parties in order to have a private communication with that party. This results in that party being split off from the conversation, the connection between the served user and the other party on the three-way call being placed on hold, and the connection between the served user and the designated party being active. Other party (B or C): Either of the other parties (Users B or C) can ask the service provider to: i) release it from the three-way conversation which results in a simple active call between the served user and the remaining party; ii) place its connection to the three-way conversation on hold (and, typically, later retrieve it); Note - While the served user is held, the other parties (i.e. served user and remaining party) may con- tinue to communicate. Note to _ 3.2.2.3 - The extent to which the service provider re-uses the existing resources (e.g. a bridge) to form the resulting, simpler call is a service provider option. 3.3 Exceptional procedures 3.3.1 Activation/deactivation/registration None identified. 3.3.2 Invocation and operation None identified. 3.4 Alternate procedures 3.4.1 Activation/deactivation/registration None identified. 3.4.2 Invocation and operation None identified, except for the point made above regarding variations due to different terminal capabilities. 4. Network capabilities for charging This Recommendation does not cover charging principles. Future Recommendations in the D-Series are expected to con- tain that information. It shall be possible to charge the subscriber accurately for the service. 5. Interworking Considerations None identified. 6. Interaction with other supplementary services 6.1 Call Waiting Assume that users A, B and C have subscribed to the Call Waiting service, then: - if a call waiting indication was presented to user A and/or userB either before or during the three-party service invocation, then the call waiting indication would still be present after the three-party service is active. While the three- party service is active, the party with the waiting call may put his/her active call on hold to accept the waiting call; - a call waiting indication may be presented to any party involved in a Three-Party Service call, and that party may: 1) be active in a two-party call (A-B or A-C), 2) be on hold (B during A-C, C during A-B), 3) be active in a three-way conversation, or 4) have their connection to the three-way conversation on hold; - it may be desirable to include a capability of accepting an incoming call as part of Three-Party Service. Currently a user could alternate between the first call and the second (waiting or answered) call by combining hold and retrieve requests. A user could also join the second (waiting or active) call to the first call by invoking a three (or more) party conference call. 6.2 Call Transfer Call Transfer can be invoked in either the "Held A<-|-->B(C)&&Active A-->C(B)" state (see SDL's for Call Transfer service) or the "Active Three-Way Conver- sation" state (see Figure 2/I.254.2, Call Transfer From "Active Three-Way Conversation" State). 6.3 Connected Line Identification Presentation This supplementary service has no impact on the operation of the other supplementary service. 6.4 Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.5 Calling Line Identification Presentation No impact, i.e. supplementary service affects the operation of the other supplementary service. 6.6 Calling Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.7 Closed User Group Assume that a user A, who has subscribed to the Three-Party Service, has an established call with user B and wishes to create a three party call by including a user C (either a minimum Three-Party Service or a three-way conversation). When user A invokes the Three-Party service and places a call to userC, the service provider shall check that all CUG conditions are met between usersA and C but is not required to check CUG conditions between usersB and C at this point since user A may wish to only have a minimal Three-Party Service call. If any of the parties to be involved in the three party call are also a CUG member, then CUG conditions must be met by all of the parties before a three-way conversation can be formed. 6.8 Conference Calling A served user who has invoked Three-Party Service to create a three-way conversation may convert the three-way conversation to a conference call by invoking the Conference Calling Service and identifying the Party Ids of the currently existing other two parties as part of the conference invocation. This requires that the served user of the Three-Party Ser- vice has also subscribed to the Conference Calling Service. For other interactions, see _6.12 "Three-Party Service" in Rec- ommendation I.254.1, Conference Calling service description. 6.9 Direct Dialling-In No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.10 Diversion services,(Call Forwarding Busy, Call Forwarding No Reply, and Call Forwarding Unconditional) If the served user attempts to establish the second call to a userC that has Call Forwarding activated, and the appro- priate forwarding conditions are met, the forwarding-to user will be alerted and treated in all other respects as if the call had been placed to him/her. 6.11 Line Hunting No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.12 Three-Party Service The served user (A) may treat a Three-Party Service call that has reached the "three-way conversation" service state as an "existing call" upon which the minimal Three-Party Service may be invoked. That is, if the served user A is in a three-way conversation with parties B and C and invokes (minimal) Three-Party Service on it, the service provider will place the served user's connection to the conversation on hold (with channel reservation) and allow the served user to establish a call to another party (D). Once the call to userD reaches the alerting state, any of the procedures in _3.2.2.2 may be used to manage the call to party D and the "three-way conversation" call. 6.13 User-to-User Signalling While adding the third party (user C) to the three party service, the served user (user A) can send and receive UUI (Services 1, 2 and 3) from the new party until the new party is added to a three way conversation. The served user will be able to send and receive UUI (Service3) to both remote parties (usersB and C) on a three-way conversation individually and in some networks optionally broadcast UUI (Service 3) messages to both parties. Note - This assumes that each party can be uniquely identified.] UUI (Service3) cannot be sent between remote parties (Users B and C) in association with the three-way conversation. 6.14 Multiple Subscriber Number No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.15 Call Hold Service A served user that has all of his/her parties on hold would not be able to invoke the Three-Party Service, since he/ she is not active on any given call. A served user A that is engaged in an active call to a userB shall be able to invoke the Three-Party Service (if sub- scribed to) to a user C that is already on hold to served user A. This will allow served user A to create a three-way con- versation with users B and A previously held) user C. Any party involved in a Three-Party Service call (either minimum service or a three-way conversation) will be able to out the Three-Party Service call on hold. Once a party puts a Three-Party Service call on hold, that party may retrieve any other call it has previously held. For any party involved in a three party call which has also subscribed to the hold service without channel reservation, that party may place the Three- Party Service on hold and 1) initiate a new call; 2) receive a call (e.g. to process a Call Waiting request); or 3) complete a call to a new free party that previously was busy and CCBS (Note) had been invoked upon. Note - The completion of calls to busy subscribers supplementary service needs further study. The Hold Service allows a user to switch (by hold and retrieve) between "parties" where a party may be a single user, a three-way conversation, or a conference call. Thus, a party in a three-way conversation may switch between the three- way conversation and another "party" hold, the "party" being a single user, another three party call or a conference call. 6.16 Advice of Charge No impact, i.e. neither supplementary service affects the operation of the other supplementary services. 7. Dynamic Description The dynamic description of this service is shown in Figure 1/I.254.2.